Reference semantics is A Good Thing. We can't live without pointers. We just don't want our s/w to be One Gigantic Pointer. In C++, you can pick and choose where you want reference semantics (ptrs/refs) and where you'd like value semantics (where objects physically contain other objects etc). In a large system, there should be a balance. However if you implement absolutely *everything* as a pointer, you'll get enormous speed hits.
Objects near the problem skin are larger than higher level objects. The *identity* of these 'problem space' abstractions is usually more important than their 'value'. These combine to indicate reference semantics should be used for problem-space objects (Booch says 'Entity Abstractions'; see on 'Books').
The question arises: is reference semantics likely to cause a performance problem in these 'entity abstractions'? The key insight in answering this question is that the relative interaction frequency is much lower for problem skin abstractions than for low level server objects.
Thus we have an *ideal* situation in C++: we can choose reference semantics for objects that need unique identity or that are too large to copy, and we can choose value semantics for the others. The result is very likely to be that the highest frequency objects will end up with value semantics. Thus we install flexibility only where it doesn't hurt us, and performance where we need it most!
These are some of the many issues the come into play with real OO design. OO/C++ mastery takes time and high quality training. That's the investment-price you pay for a powerful tool.
<<<<DON'T STOP NOW! READ THE NEXT QUESTION TOO!!>>>>
